WASI 0.2: The New Standard Interface for WebAssembly

javi
Cubos modulares conectados representando componentes de software

WebAssembly has gone from being “JavaScript but faster in the browser” to a serious platform for running portable code outside the browser. The key piece of that transition is WASI (WebAssembly System Interface), the standard defining how WASM modules access system resources (filesystem, network, time). In 2023 the finalisation of WASI Preview 2 approaches, a substantial rewrite from Preview 1. We cover what changes, why, and what impact it’ll have.

The Problem With Preview 1

WASI Preview 1 (published 2019) made WebAssembly outside the browser possible. But as the ecosystem matured, its limitations became evident:

  • POSIX-like model. Designed thinking in filesystem and Unix-style syscalls. Doesn’t fit modern cases like cloud functions, edge computing, or IoT.
  • No composability. Two WASM modules couldn’t easily “compose” with each other — communicate in rich types, not just bytes.
  • No rich types at the interface level. Just integers, floats, pointers, and memory. Strings, structs, lists required manual serialisation.
  • Limited capabilities. You granted access to the entire filesystem, not granular resources.

Preview 2 rewrites the base to solve these problems, while keeping backward compatibility with Preview 1 during the transition.

The Component Model and WIT

The central novelty is the Component Model: WASM modules as components with explicitly typed interfaces, capable of composing with each other at runtime.

Interfaces are described in a language called WIT (WebAssembly Interface Type):

package jacar:examples;

interface logger {
    log: func(message: string);
    levels: enum { debug, info, warning, error }
}

world my-app {
    import logger;
    export run: func();
}

This declares a component that imports a logger interface and exports a run function. WIT supports types like string, record (struct), variant (sum type), list, option, result. Much more expressive than integers and raw memory.

The consequence: two WASM components compiled from different languages (Rust + Go + JavaScript) can talk to each other passing rich structs without manual serialisation. It’s the foundation for an ecosystem of reusable components.

Granular Capabilities

Preview 2 introduces a much finer capabilities model. Instead of “the module can access the filesystem”, you grant access to:

  • A specific directory, read-only.
  • A TCP socket to a specific host, not the whole network.
  • A specific environment variable, not free getenv().
  • A system timer, without access to wall clocks.

This fits much better with cases like edge functions or plugins in host applications, where you want to run untrusted code with minimum permissions.

State in 2023

By late 2023, WASI Preview 2 is in release candidate phase. The official 0.2 specification is expected stabilised for early 2024.

Runtime implementations already supporting or adding support:

  • Wasmtime (Bytecode Alliance) — reference implementation, tracking the standard.
  • wasmer — progressive support.
  • WasmEdge — focus on edge and cloud-native.
  • Spin (Fermyon) — framework for WASM apps with early Component Model support.

Language toolchains adding support:

  • Rust via cargo-component.
  • JavaScript via jco.
  • Python via componentize-py.
  • Go via tinygo (partial) and experimental projects.

Use Cases That Get Unlocked

Preview 2 + Component Model enable cases where traditional WASM creaked:

  • Secure plugins in host applications. Editors, HTTP servers (Apache/Nginx modules in WASM), extensible databases. Granular capabilities avoid malicious-plugin risk.
  • Truly multilingual serverless / edge functions. A function in Python can call another in Rust without serialising to JSON.
  • Microservices in WASM. Small composable components running on lightweight runtimes (faster startup than containers).
  • Portable smart contracts. Some blockchains (Substrate, NEAR) already use WASM; the component model eases composition.
  • Embedded ML. Small models packaged as a WASM component, executable on any runtime supporting the standard.

Remaining Limitations

Still in 2023:

  • Threading and concurrency are areas with proposals but not yet standardised.
  • Garbage collection (important for languages like Java, C#, Python) in a separate proposal (WASM-GC), not yet integrated.
  • Performance in some JIT-compiled languages may not match native runtime.
  • Debug tooling is still maturing — debuggers, profilers aren’t as rich as for native code.
  • Runtime adoption in massive cases (hyperscale serverless) still incipient.

Why You Care Even If You Don’t Write WASM

As an engineer not directly touching WebAssembly, the WASM/WASI ecosystem is relevant because:

  • Edge functions at Cloudflare, Fastly, and others run WASM internally.
  • Plugins for various tools (Envoy proxy, OPA, Istio) are WASM.
  • Databases like SQLite and future Postgres versions explore WASM extensions.
  • Smart contracts and blockchains with WASM support grow.

Knowing the standard’s direction (Preview 2, Component Model) helps you understand why certain products make architectural decisions and anticipate capabilities that will arrive.

Conclusion

WASI Preview 2 is WebAssembly’s step toward “serious platform” outside the browser. The Component Model with typed interfaces and granular capabilities solves real limitations that have slowed adoption. Full standardisation arrives in 2024, but the time to start exploring is now — especially if you build tools that would benefit from plugins, edge computing, or secure execution of untrusted code.

Follow us on jacar.es for more on WebAssembly, edge computing, and platform evolution.

Entradas relacionadas